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1 

Updating data in a mobile terminal 

This invention relates to differentially updating stored data in a mobile 
terminal from a first data version to an updated data version. 

5 

IVIoblie terminals, such as mobile telephones, pagers, electronic organisers, 
smart phones, personal digital assistants (PDAs), or the like, have become 
and are continuing to become increasingly software-intense devices. As a 
consequence thereof there is a great need for proper version management 

10 and update facilities for the software stored on mobile terminals, In the future, 
software bug fixes and standard updates will be a natural part of the life cycle 
of a mobile terminal and a requirement for the terminal to function properly. 
Currently, the user of such a mobile terminal typically needs to physically visit 
an update centre where the terminal is connected, using a wire, to a 

1 5 computer in order to load and install new versions of the systems. 

In many respects, this is an unsatisfactory solution. It is expensive for the 
tenninal manufacturer and annoying for the user. Hence, it is desirable to 
avoid the need for the customer to actually visit an update centre. 
20 Furthermore, it is a disadvantage of the above solution that the update time is 
unnecessarily long, since current practice is to download, each time an 
update is required or desirable, a complete image of the memory of the 
mobile terminal, 

25 It has been suggested to introduce over-the-air (OTA) firmware updates for 
mobile terminals, thereby allowing users to get the latest version of the 
system software while being at home or on the road. An update may not 
even have to be initiated by the user, but can be started by e.g. the network 
operator over the network instead. For example, a critical patch can be 

30 distributed to all users of a specific model of a mobile telephone, without the 
need for them to actively seek new updates. 
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Hence, in an OTA solution, software updates providing added features and 
bug-fixes or updates of other data are distributed to the mobile terminal over 
the air Interface. For the purpose of the present description, the old software 
5 revision that is present on the mobile terminal is also referred to as the base 
version, while the new, updated revision is also called updated version or 
new version. Simply distributing an image of the new revision is 
unsatisfactory or even impossible for at least two reasons. The download 
time would become very long and moreover it would require the phone to 

10 keep two copies of the software at the same time, which would double the 
memory requirements. In order to solve the above issues, it has been 
suggested to only transmit the necessary changes in a so-called delta file. 
The delta file is constructed to comprise instructions allowing the mobile 
terminal to generate the new version from the base version and from the 

15 delta file, i.e. instructions for a differential update of the base version of the 
data, thereby reducing the required bandwidth for loading the software 
update as well as the required storage capacity of the mobile terminal. 

US patent 6,018,747 discloses a method of generating in-place delta updates 
20 of software on a target system, wherein the delta file comprises "copy" 
commands and "add" commands identifying changes to be made to the base 
version in order to arrive at the new version of the software. Hence, 
according to the above prior art method, upon releasing a new version of 
software, a delta file is generated from the new and the previous version. The 
25 delta file can then efficiently be distributed even over low-bandwidth 
channels. 

However, it is a problem of the above prior art system that it does not 
address some of the security issues related to OTA software updates. One 
30 requirement for secure software updates is the requirement that the resulting 
updated software version is authentic, i.e. corresponds to the software that is 
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intended to be loaded. Non-authentic or corrupted software may cause the 
mobile temninal to mal-function or even not to function at all. Con-upted 
software may be the result of malicious attacks, such as viruses, worms, etc., 
the result of another form of hacl^ing, such as tampering with licensing 
5 functions, or the result of software or hardware errors, e.g. in the case of 
memory errors. 

Hence, it is an object of the present invention to provide an update 
mechanism for a mobile terminal that provides a high level of security. 

10 

The above and other problems are solved by a method of differentially 
updating stored data, such as data representing software instructions, in a 
mobile terminal from a first data version to an updated data version, the 
method comprising 

15 - loading differential update instructions into the mobile terminal; and 

- generating the updated data version by the mobile terminal from the 
stored data and the loaded differential update instructions; 
wherein the method further comprises detecting whether the stored data In 
the mobile terminal includes one or more corrupted portions of the stored 
20 data inconsistent with the first data version; and wherein generating the 
updated data version further comprises repairing any such detected 
corrupted portions. 

Consequently, even if the base version is corrupted, by detecting the 
25 corrupted portions of the stored data, during the subsequent generation of 
the new version it is ensured that the new version is the authentic new 
version. 

Here, the term repairing the corrupted portions of the stored data is intended 
30 to comprise generating the corresponding portions of the authentic updated 
version. 
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In a preferred embodiment, the method further comprises generating the 
differential update instructions based on infomiation about the detected 
corrupted portions of data, if any. Hence, according to this embodiment a 
5 modified delta file is generated from the base version and the updated 
version and based on information about which portions of the stored data, if 
any, are corrupted, i.e. which portions of the stored data do not correspond to 
the authentic base version or, at least, are at risk not to correspond with the 
authentic base version. 

10 

For example, if the base version of the software is infected by a virus 
program, or if the base version has been tampered with, e.g. in order to 
circumvent license protection mechanisms, this may cause the software 
update to result in a corrupted memory image that may cause the mobile 
15 terminal to malfunction or the terminal may not function at all. 

It is understood that, if no corrupted portions are detected, a standanj delta 
file may be generated or, if such a standard delta file has been pre-generated 
at a previous point in time, retrieved. Such standard delta file may be 
20 generated using any suitable method of generating a delta file, e.g. the 
method disclosed in US patent no. 6,018,747. 

In a further preferred embodiment, the differential update instructions include 
update data; and generating the updated data version comprises replacing 
25 predetermined portions of the stored data by said update data. Preferably, if 
corrupted portions of the data have been detected, the update data include 
repaired portions of data consistent with the updated data version, the 
repaired portions of data corresponding to the detected con-upted portions of 
data. 

30 
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When generating the differential update instructions comprises generating 
instnjctions causing the mobile terminal to generate the updated data version 
from the stored data excluding the detected con-upted data portions, if any, 
and from the differential update instructions, only those portions of the base 
5 version, which are not corrupted, are used as a source for the differential 
updating process. Consequently, the risk of propagating the corrupted 
portions to corresponding or even further portions of the updated version is 
eliminated. 

10 Here, the term data portion comprises any part of the data that may be 
identified as such, e.g. data in a certain address range, a section of memory, 
a memory block, or the like. 

Preferably, the differential update instructions are generated on a remote 
15 data processing system, such as a software update server. Preferably, the 
remote data processing system and the mobile tenminal communicate via a 
wireless communications link, e.g. a cellular communications network such 
as a GSM network, a GPRS network, a UMTS network or another 3G 
network. The communication may be perfomied via any suitable 
20 communications protocol, e.g. an Internet Protocol (IP), such as TCP/IP, via 
a short message service (SMS), or any other suitable data transfer 
mechanism. 

In a preferred embodiment, the detection of corrupted portions is performed 
25 by the mobile terminal, and the result of the detection is communicated to the 
remote processing system, thereby reducing the amount of data that needs 
to be communicated via the air interface between the mobile terminal and the 
remote data processing system. 



30 In another preferred embodiment, the detection of the corrupted portions is 
performed cooperatively by the mobile terminal and the remote data 
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processing system. Hence, according to tiiis embodiment, the method further 
comprises transmitting Information about the stored data from the mobile 
terminal to the remote data processing system; wherein the detecting is 
performed by the remote data processing system from the transmitted 
5 information. It Is an advantage of this embodiment that it reduces the 
computational and memory resources required at the mobile terminal. It Is a 
further advantage of this embodiment that it increases the security of the 
method, since the detection is not entirely based on processes performed by 
the mobile temninal that comprises potentially con^upted data or software. 

10 

In a further preferred embodiment, the detecting comprises 

- calculating a number of checksums by the mobile tenninal, wherein 
each checksum corresponds to a corresponding portion of the data 
stored in the mobile terminal; and 
15 - comparing the calculated checksums with a number of reference 
checksums to identify any corrupted portions of data. 

Hence, an efficient and reliable mechanism for detecting conrupted portions 
of the base version is provided. For example, a checksum may be calculated 
20 block wise for respective blocks of memory of a predetermined size. When 
the calculation of the checksums is based on a cryptographically strong one- 
way hash function, the reliability of the detection mechanism is further 
increased. 

25 In one embodiment, the reference checksums are stored in the mobile 
terminal and the comparing is performed by the mobile terminal. Hence, 
according to this embodiment, the mobile terminal calculates and verifies the 
checksums and sends the result of the verification to the remote data 
processing system. 



30 
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Relying on a detection process perfonnecl entirely by the mobile terminal and 
based on reference checksums stored on the mobile terminal involves a 
security risl<, since the reference checksums themselves may be corrupted, 
e.g. tampered with. This problem is solved, when the reference checksums 
5 stored in the mobile terminal are integrity protected by a message 
authentication code. 

In another preferred embodiment, the reference checksums are stored on the 
remote data processing system; wherein the transmitted information 

10 comprises the calculated checksums; and wherein the detecting further 
comprises comparing the transmitted calculated checksums by the remote 
data processing system with the number of reference checksums stored on 
the remote data processing system. Hence, the storage of the reference 
checksums does not require storage capacity in the mobile terminal and the 

1 5 reference checksums are not vulnerable against corruption or tampering of 
the data stored in the mobile temiinal. 

Further preferred embodiments are disclosed in the dependant claims. 

20 It Is noted that the features of the methods described above and in the 
following may be implemented in software and carried out on a data 
processing system or other processing means caused by the execution of 
program code means such as computer-executable instructions. Here and in 
the following, the term processing means comprises any circuit and/or device 

25 suitably adapted to perform the above functions. In particular, the term 
processing means comprises general- or special-purpose programmable 
microprocessors, Digital Signal Processors (DSP), Application Specific 
Integrated Circuits (ASIC), Programmable Logic Arrays (PLA), Field 
Programmable Gate Arrays (FPGA), special purpose electronic circuits, etc., 

30 or a combination thereof. 
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For example, the program code means may be loaded in a memory, such as 
a RAM, from a storage medium or from another computer via a computer 
network. Alternatively, the described features may be Implemented by 
hardwired circuitry instead of software or in combination with software, 

5 

The present invention can be implemented in different ways including the 
method described above and in the following, a mobile terminal, data 
processing system, and further product means, each yielding one or more of 
the benefits and advantages described in connection with the first-mentioned 
10 method, and each having one or more preferred embodiments corresponding 
to the preferred embodiments described in connection with the first- 
mentioned method. 

The invention further relates to a mobile terminal comprising 
15 - a data memory for storing data; 

- communications means adapted to receive from a data processing 
system differential update instructions for updating data stored in the 
data memory from a first data version to an updated data version; 

- processing means adapted to generate the updated data version from 
20 the stored data and from the received differential update instructions; 

wherein the processing means is further adapted to generate information 
from the stored data indicative of the presence or absence of one or more 
con'upted portions of the stored data inconsistent with the first data version; 
and to communicate the generated infomnation via the communications 
25 means to the data processing system for generating the differential update 
instructions. 

The invention further relates to a data processing system for facilitating 
differentially updating stored data in a mobile terminal from a first data 
30 version to an updated data version, the data processing system comprising 
means for loading differential update instructions into the mobile terminal, the 
differential update instructions causing the mobile terminal to generate the 
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updated data version from the stored data and the loaded differential update 
instructions; 

wherein the data processing system further comprises 

- means for receiving information from the mobile terminal indicative of 
5 the presence or absence of one or more corrupted portions of the 

stored data inconsistent with the first data version; and 

- processing means adapted to generate the differential update 
instructions from the first and updated data versions and from the 
received information; and to include repair instructions into the 

10 differential update instructions, wherein the repair instmctions are 

adapted to cause the mobile terminal to repair any such detected 
corrupted portions. 

The invention further relates to a computer program comprising program 
15 code means adapted to cause a data processing system to facilitate 
differentially updating stored data in a mobile terminal from a first data 
version to an updated data version by performing the following steps, when 
the program is executed on the data processing system: 

- generating differential update instructions from the first and updated 
20 data versions and from information received from the mobile terminal, 

wherein the received information Is indicative of the presence or 
absence of one or more con-upted portions of the stored data 
inconsistent with the first data version; wherein generating differential 
update instructions comprises including repair instructions into the 
25 differential update instructions, wherein the repair instructions are 

adapted to cause the mobile terminal to repair any such detected 
corrupted portions; and 

- loading the generated differential update instructions into the mobile 
terminal, the differential update instmctions causing the mobile 

30 terminal to generate the updated data version from the stored data 

and the loaded differential update instructions. 
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10 



The term mobile temiinal comprises any mobile device comprising suitable 
circuitry for receiving and/or transmitting communications signals, e.g. radio 
communications signals, to facilitate data communication. Examples of such 
5 devices Include portable radio communications equipment and other 
handheld or portable devices. The term portable radio communications 
equipment includes all equipment such as mobile telephones, pagers, 
communicators, i.e. electronic organisers, smart phones, personal digital 
assistants (PDAs), or the lil<e. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other aspects of the invention will be apparent and elucidated 
from the embodiments described in the following with reference to the 
15 drawing in which: 

fig. 1 schematically shows a bloct< diagram of an embodiment of a system for 
updating software in a mobile terminal; 

20 fig. 2 schematically shows a blocl< diagram of a mobile terminal according to 
an embodiment of the invention; 

fig. 3 shows a flow diagram of an embodiment of a software update process; 

25 fig. 4 schematically illustrates the calculation and integrity protection of 
checksums; 

fig. 5 schematically shows a blocl< diagram of a mobile terminal according to 
another embodiment of the invention; 

30 

fig. 6 shows a flow diagram of another embodiment of a software update 
process; and 
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11 

figs. 7a-b schematically Illustrate an embodiment of the generation of a delta 
file in the absence and presence of corrupted memory blocks, respectively. 



Fig. 1 schematically shows a block diagram of an embodiment of a system 
for updating software in a mobile temninal. The system comprises a mobile 
terminal 101 , e.g. a mobile telephone or the lil<e, a software updating system 
10 102, and a communications networl< 103. 

The software updating system 102 may comprise a server computer having 
access to the communications networl^. In some embodiments, the 
functionality of the server computer may be distributed among a plurality of 

15 computers, e.g. computers connected via a computer network, e.g. a local 
area network, a wide area network, an Internet, or the like. The software 
updating system 102 comprises a network interface 104 allowing the 
software updating system to communicate data via the communications 
network 103. For example, the network interface may comprise a network 

20 card, a DSL modem, a gateway computer, or the like. 

The software updating system further comprises a processing unit 105, e.g. 
the CPU of a server computer, suitably programmed to control and perform 
the update process including the generation of delta files. The processing 

25 unit further comprises a version database 106 having stored therein memory 
images of at least a base version and an updated version of the software to 
be updated. In some embodiments, the version database may further 
comprise additional information, e.g. a plurality of base versions and/or 
updated versions, e.g. for different models of mobile terminals, for different 

30 groups of customers, and/or the like. 
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The communications network 103 may be any suitable communications 
networl< for communicating data between tlie software updating system 102 
and the mobile terminal 101, e.g. using a wireless communications bearer. 
For example, in the case of a mobile telephone adapted to communicate via 
5 a cellular communications network, e.g. a GSM network, a UMTS network, a 
GPRS network, or the like, the communication between the software 
updating system and the mobile terminal in connection with a software 
update is preferably performed via that cellular communications network, 
thereby avoiding the need for additional communications interfaces in the 

10 mobile temriinal. It is further understood that the communication between the 
mobile terminal and the software updating system may involve more than 
one communications networks. For example, the mobile phone may 
communicate via a base station and a cellular telecom network with a 
gateway system that, in turn, provides communication with the software 

1 5 updating system via the internet. 

Hence, in order to update software on the mobile tenminal 101 , e.g. the 
firmware or operating system of the mobile terminal, the mobile terminal 
connects to the software updating system 102. Alternatively, the software 

20 updating system may connect to the mobile terminal once an updated 
software version is available. Once connected to the software updating 
system, the mobile terminal sends information to the software updating 
system about its cun-ent software version and infomnation about the data 
currently stored in the memory, which information enables the software 

25 updating system to identify memory blocks that are coraipted or at least are 
at risk of being corrupted. The communication is performed via a suitable 
updating protocol, e.g. a protocol built on top of a TCI/iP protocol. Based on 
the information received from the mobile terminal, the software updating 
system generates a dedicated updating message comprising differential 

30 updating instructions to the mobile terminal. The differential updating 
instructions are generated such that they enable the mobile terminal to 
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generate the updated software version from the existing version already 
stored in the mobile terminal and from additional information included in the 
updating instructions. Furthemaore, the differential updating instructions are 
generated such that any coraipted memory block in the mobile temninal will 
5 be updated to an authentic block of the updated version and such that any 
corrupted memory contents are not used in the generation of the updated 
version by the mobile terminal. 

The generation of the delta file generation may schematically be illustrated by 

10 the following operations 

filenew - filSbase — * Afile. 

Correspondingly, the actual generation of the new version may then be 
1 5 perfomned by the mobile terminal according to the following operation 

filebase + Afile -* filenew- 

It is understood that the above operations of generating the delta file 
20 (denoted as "-" in the above notation) and generating the new version on the 
mobile terminal (denoted as "+" operation in the above notation) may 
comprise more or less complex operations. 

The delta file may be applied in-place, i.e. the changes are made by the 
25 mobile tenninal on the existing image, thereby requiring little additional 
storage. Furthermore, since only the delta file needs to be loaded and since 
the delta file typically is considerably smaller than the new version, the 
loading time is reduced by the above method. 

30 In one embodiment, the update process is Initiated by an update agent 
running on the mobile tenninal. The update agent controls the reception and 
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verification of the delta file. Subsequently, the update agent causes the 
mobile temiinal to be disconnected from the network and rebooted in a patch 
mode. In patch mode, the changes in the delta file are applied Incrementally 
until the new memory image is complete. 

5 

Embodiments of the updating process will be described in greater detail 
below. 

Fig. 2 schematically shows a block diagram of a mobile terminal according to 
1 0 an embodiment of the invention. The mobile terminal 201 comprises a 
communications block 210, a processing unit 21 1 , and memory units 212, 
213, and 214. 

The communications block 210 comprises circuitry and/or devices allowing 
15 radio-based communication of data via a cellular communications network. 
Hence, for the purpose of the present description, the communications block 
210 comprises receiver circuitry and transmitter circuitry for receiving and 
transmitting data signals. The communications block may further comprise 
circuitry for suitably processing the signals, e.g. modulating, coding, 
20 amplifying, etc., the signals by suitable techniques well known in the art of 
radio communications. 

The mobile terminal further comprises a processing unit 211 , e.g. a suitably 
programmed microprocessor. The processing unit is adapted to determine 
25 the version of the software stored in the mobile terminal, to calculate 

checksums of the stored software, and to generate an updated version of the 
software upon receipt of corresponding update instructions. 

The memory unit 212 has stored thereon the software and/or other data in a 
30 predetermined version. For example, the memory 212 may comprise the 
firmware of the mobile terminal that implements the basic functions of the 



wo 2005/050441 



PCT/EP2004/011500 



15 

mobile terminal when loaded into and executed by the processing unit 210. 
The firmware may further comprise an operating system allowing application 
software to be executed. Accordingly, the memory 212 may further have 
stored thereon application software providing additional functionality. The 
5 memory 21 2 is addressed using a suitable address space, thereby allowing 
the processing unit to access selected parts of the memory. In some 
embodiments the memory 212 may be logically or physically divided in a 
plurality of memory blocks. For example, the memory 212 may comprise 
flash memory allowing data to be written in blocks of a predetermined size. 

10 

In the following, it will be assumed that the memory 212 is divided in a 

number of blocks of a predetermined size denoted Bi, B2, B3 Bn- 

However, it is understood that any other addressing of the memory may be 
used, instead. It is further understood that the updating process described 
15 herein may be applied to the entire memory 212, e.g. if the entire image of 
the flash memory of a mobile phone is to be updated, or to only 
predetermined parts of the memory, e.g. If one or more software applications 
are to be updated. 

20 The mobile terminal 201 further comprises a memory section 213 having 
stored thereon a list of reference checksums for use in the detection of 
possibly corrupted memory blocks. The generation and use of the 
checksums will be described in greater detail below. It is understood that the 
memory sections 212 and 213 may be part of the same physical memory, or 

25 they may be physically separate memories. 

In a preferred embodiment, the mobile terminal further comprises a memory 
section 214 for securely storing a secret key for use in the integrity protection 
of the stored checksums as will be described in greater detail below. For 
30 example, the secret key may be stored in an internal memory, such as a 
ROM, an EPROM, or the like, that cannot be accessed from outside a 
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predetermined circuit of tlie mobile terminal. In other embodiments, the 
mobile terminal may comprise a unique chip-ID, e.g. burnt into a circuit of the 
mobile tenminal by means of electronic fuses. In yet other embodiments the 
secret key may be stored encrypted on a non-protected memory, e.g. a flash 
5 memory. 

Fig. 3 shows a flow diagram of an embodiment of a software update process. 
The flow diagram illustrates on its right side, generally designated 321, the 
steps performed by the mobile terminal and, on the left side generally 
10 designated 322, the steps performed by the software updating system. 

In the flow diagram of fig. 3, it is assumed that the software updating system 
initiates the update process. Accordingly, in the initial step 331 , the software 
updating system sends a message to the mobile terminal infomning the 

15 mobile temiinal that a new version of the software Is available, e.g. by 
sending an identification of the new version, designated ID_V2. In step 332, 
in response to the message received from the software updating system, the 
mobile terminal calculates the checksums of the content of the con'esponding 
memory blocks of the memory 312, or of a part of the memory comprising the 

20 software to be updated. 

In step 333, the mobile terminal compares the calculated checksums with a 
list of reference checksums stored in memory section 313 of the mobile 
terminal. The reference checksums are the checksums of the corresponding 
25 memory blocks for the authentic memory content corresponding to the base 
version currently installed in the mobile terminal. An example of how the 
checksums are stored and calculated will now be described with reference to 
fig. 4. 

30 Fig. 4 schematically illustrates the calculation and integrity protection of 
checksums. Fig. 4 schematically shows the memory 413 of a mobile device 
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that is to be updated. The memory is divided Into a set of N blocks denoted 

Bi, B2 B|si. According to this embodiment, the mobile terminal further 

comprises a memory section 413 having stored therein N+1 checksums 
conresponding to the authentic memory image of the N memory blocks of 
5 memory 413. N of the N+1 checksums are computed over respective ones 
of the N memory blocks such that there is stored a reference checksum for 

each of the memory blocks Bi On. The checksums for the individual 

memory blocks are denoted CRCi, CRC2 CRCn. Preferably each of the 

checksums is computed from the corresponding memory block using a hash 

10 function h according to CRQ = h (Bj). Preferably, the hash function is a one- 
way hash function, more preferably a cryptographlcally strong one-way hash 
function, in order to Increase the security against tampering with the update 
system. The term "cryptographically strong one-way hash function" is 
Intended to comprise any function M h(M) = m that maps messages M 

15 from a message space to a smaller hash space such that it is 
computationally infeaslble for anyone to find two messages M and M' such 
that h(M) = h(M') or, given an arbitrary m, to find any message M such that 
h(M) = m. Examples of suitable hash functions include SHA-1 and MD5, 

20 The remaining one of the N+1 checksums, denoted CRCt is calculated over 
the entire memory 412, i.e. CRCj = h(Bi, B2, Bn). In one embodiment, this 
total checksum is used to perform an initial check including calculating and 
comparing the total checksum. If the total checksum is successfully verified, 
the system assumes that there are no corrupted memory blocks. A 

25 calculation and comparison of the individual checksums is only performed, if 
the total checksum fails, in order to identify which blocks are corrupted. 

In one embodiment, the list of checksums of the authentic memory content is 
stored in the mobile terminal using a mechanism for integrity protection 
30 allowing the detection of any tampering with the list of checksums. For 
example, the list of checksums may be protected by a message 
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authentication code (IV1AC) using a secret key l< stored in a secure memory 
section 414 of the mobile terminal. An example of a message authentication 

code is HMAC. Hence, in one embodiment, a tag value t = MACk(CRCi 

CRCn, CRCt) is calculated from the checksums using a MAC algorithm and 
5 the secret k. The calculated tag value is appended to the list of reference 
checksums and stored in the memory section 413, as indicated by reference 
numeral 415. During the update process, the mobile terminal re-calculates 
the tag value using the key k and compares the calculated value with the tag 
value 41 5 stored in memory. 

10 

In order to provide a sufficiently high security of the fVIAC-based integrity 
protection, it is preferred that the key k is stored in a memory 414 in such a 
way that it can be accessed/read by a tnjsted process/user only, e.g. as 
described in connection with fig. 2 above. 

15 

Again referring to fig. 3, in step 333, the mobile terminal identifies memory 
blocks, if any, for which the calculated checksum differs from the reference 
checksum stored by the mobile terminal. 

20 in step 334, the mobile device sends an identification of the software version 
currently installed, designated ID_V1, and the list of corrupted memory 
blocks to the software updating system. In the example of fig. 3, this list 
comprises block identifiers BC1 BCK, 0 ^ K < N. 

25 Upon receipt of this information, the software updating system generates a 
suitable delta file. In the embodiment of fig. 3, in step 335 the software 
updating system determines whether the mobile terminal has identified any 
cormpted blocks. If this is not the case, i.e. if the memory contents have been 
verified by the mobile terminal as being the authentic base version, the 

30 software updating system does not need to generate a dedicated delta file. In 
this case a standard delta file comprising differential update instructions for 
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the update from an authentic base version to the desired updated version 
may be pre-generated and stored in the version database 306 of the software 
updating system. Hence, if no corrupted blocks have been identified, the 
process continues at step 336, where the software updating system retrieves 
5 the con-esponding standard delta file from the database 306 and continues at 
step 338. 

If one or more corrupted blocks have been identified, the process continues 
at step 337, where the software updating system generates a dedicated delta 

10 file and continues at step 338. As described in greater detail herein, the 
dedicated delta file comprises update instmctions that cause the mobile 
terminal to generate an authentic updated version. In particular, the update 
instructions cause the corrupted blocks to be excluded from reuse during the 
generation of the updated version. Hence, the software updating system 

1 5 retrieves the base version and the new version from the version database 
306 and generates the delta file from these two versions and from the 
infomiation about con-upted memory blocks. An example of the generation of 
a dedicated delta file in the presence of corrupted blocks will be described in 
connection with figs. 7a-b. 

20 

In step 338, the software updating system sends the generated delta file to 
the mobile terminal. In step 339, the mobile terminal generates the updated 
version of the software from the content of the memory 312 and the 
instructions received in the delta file. The mobile terminal stores the updated 
25 version in the memory 31 2. 

In the embodiment of fig. 3, the reference checksums stored in memory 313 
are also updated in order to reflect the updated memory content. Hence, in 
step 339, the mobile terminal further calculates and stores updated reference 
30 checksums and, if integrity protection is applied, an updated MAC value 
using the key k. It is understood that, in an alternative embodiment, the 
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updated reference checksums and MAC value may be calculated by the 
software updating system and transmitted to the mobile terminal instead. 

It is further understood that, in some embodiments, the mobile tenninal 
5 performs a verification of the received delta file prior to applying the received 
delta file, e.g. by applying an integrity protection of the received delta file 
and/or authentication of the softv»/are updating system. 

Optionally, upon successful completion of the update, in step 340, the mobile 
10 terminal sends an acknowledgment of the successful receipt to the software 
updating system. The receipt of this acknowledgment by the software 
updating system in step 341 completes the update process. 

In the following, a second embodiment of the update process will be 
1 5 described with reference to figs. 5 and 6, in which the detection of corrupted 
blocks is performed cooperatively by the mobile tenninal and the software 
updating system. 

Fig. 5 schematically shows a block diagram of a mobile terminal according to 
20 another embodiment of the inventksn. The mobile temiinal 501 comprises a 
communications block 510, a processing unit 511, and a memory unit 512, 
e.g. as described in connection with fig. 2. The mobile terminal 501 differs 
from the mobile terminal of fig. 2 in that the mobile terminal 501 does not 
comprise memory sections for storing reference checksums or a key 
25 parameter for the integrity protection of the reference checksums. 

An update process that can be used in connection with the mobile terminal of 
fig. 5 will now be described with reference to fig. 6. The process of fig. 6 is 
similar to the process of fig. 3, except that the mobile terminal in the process 
30 of fig. 6 sends the calculated checksums to the software updating system 
which performs the comparison of the checksums with reference checksums. 
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thereby reducing the storage requirements and the required computational 
resources at the mobile terminal. 

The flow diagram illustrates on Its right side, generally designated 621, the 
5 steps performed by the mobile tennina! and, on the left side generally 
designated 622, the steps performed by the software updating system. 

In the flow diagram of fig. 6, it is assumed that the software updating system 
initiates the update process. Accordingly, in the initial step 631, the software 

10 updating system sends a message to the mobile terminal informing the 
mobile terminal that a new version of the software is available. In step 632, in 
response to the message received from the software updating system, the 
mobile terminal calculates the checksums of the content of the corresponding 
memory blocks of the memory 612 or part of the memory comprising the 

1 5 software to be updated, as was described in greater detail above. 

In step 634, the mobile terminal sends an identification of the software 
version currently Installed and the list of calculated checksums, designated 
CRC1 CRCN, to the software updating system, 

20 

Upon receipt of this Infonnation, in step 633, the software updating system 
compares the received checksums with a list of reference checksums stored 
In the version database 606. Alternatively, the reference checksums may be 
stored at an alternative location, or the software updating system may re- 
25 calculate the checksums from the authentic base version stored in the 
version database 606. An embodiment of the structure of the reference 
checksums and a method of calculating them has been described in greater 
detail above. 



30 It is understood that, optionally, the mobile terminal may integrity protect the 
checksums prior to sending them to the software updating system, e.g. by 
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appending a MAC tag as described above, and/or cryptographically protect 
tinem in another suitable way. 

In step 635 the software updating system determines whether the 
5 comparison of step 633 has revealed any cornjpted memory blocks. If no 
corrupted blocks have been identified, the process continues at step 636, 
where the software updating system retrieves the corresponding standard 
delta file from the database 606 and continues at step 638. 

10 If one or more corrupted blocks have been identified, the process continues 
at step 637, where the software updating system generates a dedicated delta 
file and continues at step 638. 

In step 638, the software updating system sends the generated delta file to 
1 5 the mobile terminal. In step 639, the mobile terminal generates the updated 
version of the software from the content of the memory 612 and the 
instmctions received in the delta file. The mobile terminal stores the updated 
version in the memory 612. 

20 Again, it is understood that, in some embodiments, the mobile terminal 

performs a verification of the received delta file prior to applying the received 
delta file, e.g. by applying an integrity protection of the received delta file 
and/or authentication of the software updating system. 

25 Optionally, upon successful completion of the update, in step 640, the mobile 
terminal sends an acknowledgment of the successful receipt to the software 
updating system. The receipt of this acknowledgment by the software 
updating system in step 641 completes the update process. 

30 In a modification of the process of fig. 6, the mobile terminal initially 
calculates a total checksum of the entire memory to be updated and 
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transmits the total checksum to the software updating server for verification. 
If the total checksum is verified successfully, the software updating system 
proceeds by sending a standard update file to the mobile terminal. If the 
verification of the total checksum fails indicating the presence of at least one 
5 comjpted block, the software updating system requests the mobile tennlnal 
to send a list of checksums for the Individual blocks, in order to identify which 
block(s) is/are con-upted. 

Figs. 7a-b schematically illustrate an embodiment of the generation of a delta 
10 file in the absence and presence of corrupted memory blocks, respectively. 

As described above, a delta file comprises differential update instructions for 
generating an updated version of a file or other memory content from a 
baseline version of that file. An embodiment of the delta file generation 
1 5 procedure makes a byte-level comparison of the baseline version and the 
updated version. In the following, the baseline version will be denoted V1 and 
the updated version V2. 

Several delta file generation algorithms are known as such in the art, e.g. the 
20 algorithm disclosed in US 6, 018, 747. Typically, such algorithms scan both 
versions VI and V2 and try to find as many similarities as possible. The 
positions and sizes of the common data sections are recorded and stored. 
The delta file itself typically consists of a number of commands, e.g. add 
commands and copy commands. The copy command identifies data that 
25 should be reused from version V1 , while the add command represents data 
that is introduced, i.e. added, in version V2. 

In the simple example of figs. 7a-b, it is assumed that a baseline version of a 
file or memory area, generally designated 751 , comprises five blocks of data 
30 designated B1 , B2, B3, B4, and B5, respectively. The data stored in these 
blocks is denoted by A, B, C, D, and E, respectively. The updated version of 
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the file, generally designated 752, also comprises five blocks designated B1 , 
B2, B3, 84, and 85, respectively. However, the content of the various blocks 
differs from the con-esponding content of the baseline version. In the updated 
version, the five blocks comprise data denoted D, A, F, G, and B, 
5 respectively. Here, same letters correspond to Identical data, and different 
letters indicate different data. 

The dashed arrows in figs. 7a-b mark blocks that are common to the two 
versions. Hence, in the example of figs. 7a-b, updated block 81 comprises 
10 the same data as block B4 in the original version, updated block B2 

comprises the same data as block B1 in the original version, and updated 
block 85 comprises the same data as block B2 in the original version. 

During the updating process, the version V1 is transformed into version V2 
15 by applying the commands in a delta file. An example of a delta file 

comprises a description on how to construct version V2 from version VI 
using block-by-block copy and add operations. In the example of fig. 7a, the 
delta file 753 comprises five commands: 

20 1 . 85: CP 82 

2. B2: CP B1 

3. B1:CPB4 

4. B3: AD <F> 

5. 84: AD <G> 

25 

Each command identifies a block of the updated version and a command as 
to how to generate that block. In this example, the first command causes the 
block B5 to be generated by copying the original content of 82 into block 85. 
Similarly, the second and third commands cause blocks B2 and 81 to be 
30 generated as copies of original blocks 81 and 84, respectively. The fourth 
and fifth commands are add commands that specify that data F is to be 
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added into block B3, and that data G is to be added into blocl< B4, 
respectively. It is noted that the order of the above sequence of commands Is 
chosen such as to avoid read/write conflicts where a block is written to before 
the original content of the block is to be read. 

5 

The above update procedure relies on the fact that the version V1 image 
used by the delta generation algorithm is identical to the version V1 image on 
the mobile terminal. In a situation where this is not the case, e.g. the target 
node image has been tampered with or is infected with some virus, there is a 

1 0 big risk that the update procedure will fail and render a completely non- 
functional target node. To avoid this, the status of the target image is 
checked and a report is submitted to the software updating system before the 
delta file is generated. In case some non-identical blocks are found these are 
excluded from the delta file generation. This means that the delta file may be 

15 larger than the standard delta file, since an add command containing a fresh 
copy of the corrupted block may be used instead of copy command. 

Fig. 7b illustrates an example of a delta file generation with a corrupted block. 
In fig. 7b the same scenario as in fig. 7a is considered, except that in fig. 7b it 
20 is assumed that block B2 has been detected to be corrupted. 

Consequently, in the modified delta file generation, the corrupted block 82 is 
excluded when the versions are compared for similarities, and the con-upted 
block 82 is not reused for the generation of updated block 85. Therefore, in 
25 this case, the resulting delta file 754 differs from the previous delta file in that 
the delta file 754 comprises a different command for updating block 85, 
which now reads 

1. B5:AD<B>. 

30 
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Hence, instead of a copy command the authentic updated data B is now 
explicitly added to block B5. It Is further noted that, for the purpose of the 
present description, the order of commands has been maintained. However, 
in the exampie of fig. 7b, the above step 85: AD <B> may also be perfonned 
5 as the last step, i.e. in line with the sequence of blocks, since the command 
for modifying block B5 no longer depends on the content of one of the other 
blocks. Hence, in another embodiment, the sequence of commands would be 
(2,3,4,5,1). 

10 It is understood that the scenario of figs. 7a-b merely serves as a simple 
example in order to illustrate the effect of corrupted images on the update 
process. 

In particular, it is noted that the updating steps may involve a different 
1 5 granularity than block-by-block update. The copy and add commands may 
involve smaller and/or larger memory sections. In particular, the granularity of 
the add and copy commands is not limited to the block size of the blocks that 
are detected to be corrupted or not. The add and copy commands may even 
involve memory sections of varying size. For example, each copy or add 
20 command may indicate a start address and a length of the data area that is 
to be copied or added. 

It is further understood, that the delta file may comprise additional and/or 
alternative commands, e.g. a delete command, or the like. 

25 

It is further understood that the delta file may specify an order of update 
steps that is different from the sequence of memory sections in the updated 
file, e.g. in order to avoid conflicting update steps, e.g. that a memory block is 
updated in a first step and the original content of that memory block is to be 
30 reused in a subsequent update step. 
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It is further understood that, in an alternative embodiment, the additional new 
data may be sent in a separate file, such that a command file and a data file 
are transmitted. 

5 Although preferred embodiments of the present invention have been 

described and shown, the invention is not restricted to them, but may also be 
embodied in other ways within the scope of the subject matter defined in the 
following claims. For example, even though the invention was described 
mainly in connection with the update of software, a sl<illed person will 
10 appreciate that the invention may also be applied to the update of other data 
stored in a mobile terminal. 

According to another possible modification of the update process described 
herein, the software updating system may, if corrupted memory blocks are 
15 detected, perform alternative or additional steps, e.g. the software updating 
system may deny a software update due to security reasons, e.g. if memory 
blocks comprising license-related data are corrupted. 

According to yet another possible modification of the update process 
20 described herein, the update process is initiated by the mobile terminal 
instead of the software updating system. For example, the mobile terminal 
may send a query for available updates to the software updating system. In 
some embodiments the query may include version information of the 
currently installed software. For example, the mobile terminal may send such 
25 a query at regular time intervals, in response to a user command, In 
response to another event, and/or the like. In some embodiments, the mobile 
terminal may check its memory, e.g. at regular time intervals or triggered by 
another event such as a user command. For example, the memory check 
may comprise a calculation of checksums and a comparison of the 
30 checksums with reference checksums stored by the mobile terminal as 
described above. If the memory check reveals any con-upted blocks, the 
mobile terminal may request an unconditional software update, i.e. 
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irrespective of wlietlier a new version is available, thereby allowing a repair 
of the con-upted memory content. In ottier embodiments, the mobile terminal 
may regularly calculate the checl^sums and send them to the software 
updating system where there are verified as described above. If con-upt 
5 memory blocks are found or a new software version is available, a software 
update is initiated by the updating system, 

According to yet another possible modification of the update process 
described herein, the software updating system pre-calculates a number of 

10 alternative delta files, e.g. a set of delta files, each corresponding to a single 
corrupted block. The pre-calculated alternative delta files are stored and may 
be retrieved during the actual updating process, thereby reducing the 
processing necessary during the actual update process. Alternatively or 
additionally, the software updating system may cache or store the delta files 

15 computed during the update process, thereby making them available for 
future update situations where the same corrupted blocks are identified. This 
may be particularly advantageous, in situations where the corrupted memory 
is caused by a virus or the like, since it may be expected that several mobile 
terminals will have con-esponding corrupted blocks, 

20 

The invention can be implemented by means of hardware comprising several 
distinct elements, and by means of a suitably programmed computer. In the 
device claims enumerating several means, several of these means can be 
embodied by one and the same item of hardware, e.g. a suitably 
25 programmed microprocessor or computer, and/or one or more 
communications interfaces as described herein. The mere fact that certain 
measures are recited in mutually different dependent claims or described in 
different embodiments does not indicate that a combination of these 
measures cannot be used to advantage. 

30 

It should be emphasized that the term "comprises/comprising" when used in 
this specification Is taken to specify the presence of stated features, integers. 



wo 2005/050441 



PCT/EP2004/0I1500 



29 

Steps or components but does not preclude the presence or addition of one 
or more otiier features, integers, steps, components or groups thereof. 



